Mac Mania 2/MacMania 2.toast/Demo's/Tools&Utilities/PowerPC/PPC News 3012

Text File | 1994-05-03 | 11.9 KB | 219 lines | [TEXT/ERIC]

CLIENT/SERVER - THE CRACKS APPEAR

Software Futures is extremely fed up with this mess called
client/server.

Oh, you didn't know it was a mess? You just plug a few Windows PCs
together, stick Sybase on a Unix server, maybe bung in a gateway to
talk to the IMS database on the mainframe, and Bob's your uncle,
right? (And client/server means the same as Unix and downsizing, of
course.) What could be simpler - they're all standard pieces by now.
And hey presto, you save millions of pounds, automatically,
overnight, guaranteed. Because client/server is cheaper, right? Old
computer solutions are evil and were concocted by people who fought
in World War II, and we know better, correct? And open systems means
the best deal for the customer because choice guarantees quality and
honesty.

If you believe this list of nostrums then you don't deserve to hold
your current position.

As a manager, as a developer of systems that are supposed to be of
some earthly use, or as a user who should be informed enough to know
he's being hoodwinked - it's just not good enough to believe all of
that received wisdom. In fact, it's irresponsible. Let's see if we
can enlighten you on a few home truths.

Last summer Software Futures attended DB/Expo, the best trade show
we've ever been to, in San Francisco. 25,000 other delegates seemed
to think so, too. In this article we'll try and share just why it
was so good: and why it's helped drive us to the stage where we're
totally fed up with the drivel we're told, and constantly repeating
to each other, about the practical reality of building computer
systems in the mid-1990s.

We'll concentrate on a presentation given by a chap called Richard
Finkelstein, president of Chicago based Performance Computing.
(Finkelstein can be contacted on [phone] 8325.) Richard is
very unhappy with client/server too.

You see, he wants to go home at a normal time occasionally. He'd
like to have the odd weekend free, and take his children to the zoo.
Does this sound so bad or difficult to achieve? Well, no, you might
say. What's his problem?

"I'm tired of the 5pm to midnight shift and I'm tired of working
every weekend. I spent a whole weekend once on a client/server bug
that turned out to be a Goddam printer cable problem! I think it's a
good thing Bill Gates is getting married, because then he may find
out there's more to life than working on computers," thundered
Finkelstein at the start of his outstanding one day seminar,
"Evaluating and Using SQL Client/Server Software." You see, Rich has
been working too hard. That's because he is a dedicated software
professional, who believes in what he does. So when these
client/server bolt-together systems you believe are so easy to build
don't work, which is nearly all the time, he feels he has to try and
fix them. He says he feels he's had a good day when the things print
- just that, and he feels relieved and that he's accomplished
something. And he's not going to take it any more, quite frankly.

What is client/server? The simplest scenario involves among other
complexities this: A set of function calls, or APIs (application
programming interfaces), are used by a software application to
request information from a database, usually over a network. The API
sends requests or statements in a language called SQL into the
network library to talk the right fragment of TCP/IP or named pipes
or NetWare or whatever to get the data back. Every vendor provides
different, specific bits, which you have to install.
It's supposed to be like using the telephone. It's not. " In
reality, nothing is transparent to the network, and it's not plug
and play. With a network, for instance, what memory chip you use
can have a big impact," says Finkelstein. "Nothing is easy in this
world - especially client/server. If vendors tell you it is, they're
either naive or don't know what they're talking about."

Take standards. Take them right out of the whole picture, and throw
them as far away as you can, in fact.

We can evolve a Standard Rule right here: "By choosing a
standards-based way of doing things in the client/server world, I am
happy to sacrifice performance and features in favour of portability
and conformance." Read this sentence as many times as you need to
really understand it. Get real - you know that this is how it works
in IT. This is the world of computer vendors like IBM and Oracle,
remember. If you're happy with that, follow it through in your
expectations of what these systems will do for your company - as
we'll keep reminding you in this piece, that's the bunch of funny
people down the hall who pay your wages and who sell things. Now and
again, they might want you to build Tem something to save or make
money.

For instance: Middleware is very important in building client/server
systems. One of the basic components is the API level. At the top
level sits the application - if you've lost track of why this is
important in all this chaos, that's what we're supposed to be doing
all this for - which may speak to Excel, or Focus, or PowerBuilder
or whatever. Underneath may be a whole layer: Excel using Microsoft
DLL calls, the PowerBuilder app speaking to an rdbms API like
Sybase, a "standard" API like ODBC, or Focus speaking to a "gateway"
API like EDA/SQL. (All of these may be intercommunicating with each
other at this level.) Then this layer will be speaking to specific
dbms drivers, which will speak to LAN network drivers or to a WAN
gateway. Phew. With us so far?

Now in the bad old days, goes the argument, you had to use the API
that came with your Oracle or Informix or whatever rdbms, so you had
to stick with that one. So what users really wanted, or were told
they wanted - and people like me in the press are just as guilty as
the vendors here - was an open API so they could have one for all
uses, have portable applications, not be dependent on one rdbms
vendor, etc etc. This is what things like SQL Access Group (SAG) and
so on are all about. The promise is that we'll end up with one API
that works with all database servers. BUT! Following the
practicality line, think about it: using the native rdbms API
maximises performance and functionality (remember, the Standard
Rule), and means it's not dependent on any other vendors, meaning
release synchronisation is much easier.

This point is INCREDIBLY important to understand. Consider a
consortium like the SAG. It's made up of 44 vendors. Have you ever
seen anything useful come out of a body with that many (often
viciously competitive) players? The Group has tried, nobly, to
wrestle with some difficult issues, sure - SQL syntax and semantics
differences, codification of data types, error handling and
reporting, catalogue table issues and do forth. But as Finkelstein
says, "It's not completed, IBM does not participate, and no-one has
implemented it and no-one will." Why? Because there are already too
many standard APIs, and they're not provided by neutral bodies -
basically, they are either for or against Microsoft/IBM. Instead of
proprietary APIs we have standard proprietary APIs! This covers
ODBC, IDAPI, Oracle Glue (or as Finkelstein jokes, "Glue users to
Oracle - this appears to be another marketing announcement with no
engineering") and so on.

For your information: Microsoft's Access does not support the latest
ODBC. So the vendor can't even support its own standard! "What do you
gain from using ODBC or IDAPI but an extra layer of complexity? Does
anyone really want to do this?" asks Finkelstein, noting with a
straight face, "It may be useful for very simple applications."

Think about, for instance, ODBC. It's based on the SAG call level
interface - with "extensions." It's still evolving. It's still got
big performance and memory overhead problems. There are few drivers
built, and it's hard to build one. There are many sorts of
conformance levels, core, level 1 and level 2. It's also owned by
Microsoft. That means to build drivers, (a) you have to depend on
Microsoft to keep synchronised with all the other vendorsU new rdbms
APIs - and standards are ALWAYS behind the latest release - and (b)
as a vendor you have to go to Microsoft and tell it what you're
going to be doing with your database so it can build the drivers!

Follow it through. The application talks to the IDAPI API which
talks to the IDAPI driver which talks to the ODBC API which talks to
the ODBC driver... what if they don't translate properly? What if
they're unable to translate? What if they translate but it takes so
much steam out of the system the users throw their mice at the
screen in disgust? What if vendor A's release is one release behind
the ODBC spec vendor B is following? What if Microsoft decides it
wants to favour vendor P's implementation of row level locking over
vendor Q's? What if you sell the idea of openness to you boss, spend
=9C500,000 on this junk, and it just doesn't do what it tells you in
the standards brochure (question: do code examples in books EVER
work)? Stand there wringing your hands and say it should, because
it's standard? What are you going to do - cry?

You may want to open the window in shock at this point. It's a
cliched image, but this really is the Emperor's new clothes time.
We're all for standards in some way - it should be the genuine route
for user independence. But in the real world, the world where you
want to be able to have time to take your kids to the zoo, the free
market has given us just a mess (Finkelstein's phrase). Software
Futures will spell it out. Things like ODBC are not useful to you,
or likely to be before the next Ice Age. Do not bother reading about
them. Do not listen to a vendor telling you about them. Do not buy a
product because it says it is conformant to open standard X. Do not
expend effort tracking which vendors say they adhere to any of them.
Worry about building simple, useful computer systems for your users
which work, that won't drive you into the ground building, and which
won't take three times as much maintaining as the old dumb terminal
version. If that means buying everything from one vendor - DO IT! As
Finkelstein says, "Homogeneity means more time spent on application
development and less time spent on connectivity and other networking
issues. It also means more time with the family - and having a
life."

"Just write to the native API already! Write an application for one
database server - if you can do that you'll still be ahead of the
game. But in fact what you should do is hint to your rivals that
you're not, so you'll have a dozen applications in the field while
they're still layering IDAPI on ODBC APIs..." is Finkelstein's sly
advice.

Back to that list of assumptions about client/server. We've picked
on one tiny part of the client/server world to illustrate a point:
these systems are NOT as easy to build or maintain as they tell you.
Instant panaceas like open proprietary standards are a nice example,
because they show that when it comes down to building useful, real
world applications, they're not much use.

Next month Software Futures will also try and explain the following:
that client/server is NOT the same thing as Unix and downsizing;
that client/server is NOT automatically cheaper than other
solutions, and that if you go in with that assumption you'll get
burned; why 30% of Business Process Re-engineering projects, often
given as the motivation for a move to client/server, FAIL; why you
should go client/server and when; why open systems has given us as
many problems as the old way; which products a seasoned practitioner
like Finkelstein recommends for building such systems, and why; and
why there are MAYBE 100 successful client/server systems worthy of
the name, worldwide, now, seven years after Sybase coined the term.
Client/server might be a good idea; it may even be a good idea for
your company. Software Futures thinks you might want to hang on just
a little while longer to find out which products Finkelstein uses in
a project when he wants to go home at the same time as all the other
humans. Could be you want to as well.
Unless you like mess.

(c) Software Future - select 5004 for more details